انضم إلى تحدي Gate.io للمشاركة في الاحتفال بيوم عيد الشكر لمدة 15 يومًا واربح حصة من مكافآت قيمتها 2000 دولار!
للاحتفال بعيد الشكر! يطلق Gate.io تحدي النشر لمدة 15 يومًا! انضم إلى Gate Post للفوز بحصة من 2،000 دولار. هناك أيضًا البضائع الحصرية لسفراء Gate Post!
🔎 للانضمام:
انقر على النموذج في الإعل
كيفية إزالة مناوبة
MEV-Boost هي عربة جانبية لاستخراج MEV في بورصة ETH الحالية ، والتي تعتمد بشكل كبير على مشارك مركزي يسمى مناوبة. نقترح بنية بديلة تسمح بالاتصال المباشر والخاص المشفر بين البناة والمقترحين. تعتمد هذه البنية على شكل جديد وغير تفاعلي من تشفير العتبة "الصامت" الذي يمكنه استخدام أزواج BLSالممفتاح السري الحالية.
بصورة أساسية، نقترح عن طريق التشفير بوابة الكتل أن نرسلها إلى جزء من المشاركين، بهدف تحقيق الخصوصية وتوفير البيانات من خلال لجنة البرهان. إن دليلهم يشكل مفتاح الفك المشفر؛ عندما يتم الوصول إلى الحد الأدنى المطلوب، يمكن فك تشفير الكتلة.
تم حل حلول البناء الخاصة بنا مشكلة الخصوصية بين المُنشئ والمقترح، ولكنها وحدها لا تضمن كفاءة الكتلة. يمكن أن تُدمج مع آليات أخرى لتكرار تماماً مناوبة المقدمة، بما في ذلك الخصوصية وكفاءة الكتلة. على سبيل المثال، يمكن استخدام بيئة التنفيذ الموثوقة (TEE) أو إثبات المعرفة الصفرية (ZK)، أو من خلال آلية تشفير لتوفير ضمانات للمُنشئ.
من خلال القضاء على الحاجة للمناوبة لتوفير الخصوصية للمبنيين وضمان صحة الكتلة، نهدف إلى تقليل وقت الاستجابة وزيادة اللامركزية وقدرة التحقيق في إثراء.
دور تعزيز MEV والمناوبة
MEV-Boost هو بروتوكول وسيط يعمل كوسيط بين بناة الكتل والمقترحين، والدور الأساسي للمناوبة هو توفير ضمانين: الدور الأساسي
ومع ذلك، فإن الاعتماد على المناوبة يؤدي إلى تركيز مركزي كبير. حوالي 90٪ من كتل بلوكشين ETH يتم تمريرها من خلال عدد قليل جدًا من المناوبات. هذا ينطوي على عدة مخاطر:
تي بوست
واحدة من الاقتراحات الرئيسية كبديل لمناوبة هي "TEE-Boost"، وهو يعتمد على بيئة التنفيذ الموثوقة (TEEs). يجب ملاحظة أن TEEs ليست جوهر خطتنا؛ استخدام TEE-Boost كمثال تعليمي للمشكلة التي نسعى لحلها سيكون مفيدًا.
بشكل محدد، يتطلب TEE-Boost من البنائين استخدام TEEs لإنشاء البراهين وعرض صدق عروضهم وفعالية الكتلة للمقترحين دون الحاجة إلى الكشف عن محتوى الكتلة الفعلي للمقترحين. يمكن للمقترحين التحقق من هذه البراهين على الأجهزة العادية دون الحاجة إلى تشغيل TEEs بأنفسهم.
على الرغم من ذلك ، يوجد مشكلة في توافر البيانات في TEE-Boost: يشارك المنشئ فقط الإثباتات TEE ورأس الكتلة مع المقترح ، وليس المحتوى الفعلي للكتلة [1]، ومن الممكن أيضًا اختيار عدم إطلاق محتوى الكتلة بعد توقيع المقترح على الرأس (على سبيل المثال، إذا تغيرت الظروف السوقية بشكل غير ملائم). من الطرق المقترحة لحل هذه المشكلة في توافر البيانات:
TEE-التخزين: TEE-التخزين يحصل على الكتلة من المنشئ قبل توقيع المقترح ويطلق الكتلة بعد رؤية رأس التوقيع.
التشفير的كتلة
هذين الأسلوبين لديهما عيوب. تمثل حلول تخزين TEE نسخًا من وسيط مركزي موجود بالفعل ووقت استجابتها متحرك SUP [2] . إذا تم استخدام طبقة DA الخارجية ، فإنها ستقدم افتراضات بروتوكول إضافية وستتحمل الديناميكية الوقتية لهذا البروتوكول الخارجي (وقد تكون هذه الديناميكية أيضًا غير مفضلة).
في النظرية، إذا كانت المقترحة قادرة على الوصول إلى TEEs، فيمكن للمنشئ تشفير الكتلة إلى TEE المقترحة. سيتم فك تشفير الكتلة فقط بعد توقيعها من قبل TEE المقترحة. ومع ذلك، نعتقد أن TEE-Boost لم تنظر إلى هذا التصميم، لأن هذا سيتطلب من المقترحة (المدققون) تشغيل TEEs. نأمل أن المدققون يكونوا قادرين على العمل على الأجهزة العادية. ↩
إذا قام المقترح بتشغيل حافلة جانبية لتشغيل TEE-التخزين الآمن كجزء مشترك مع عقدة المدققين الخاصة به ، فيمكن تجنب وقت الإستجابة.
ومع ذلك ، فإننا لا نرغب أيضًا في تشغيل المدققين TEEs. ↩
تشفير العتبة لخصوصية المنشئ
قمنا بتقديم حل أنيق لمشكلة توفر البيانات في TEE-Boost: تشفير الحدود للجنة التحقق. على وجه التحديد ، يقوم المُنشئ بتشفير الكتلة بنسبة محددة من اللجنة التحقق إلى الفتحة المحددة. بمجرد جمع ما يكفي من الشهادات ، يمكن فك تشفير الكتلة وجعلها متاحة.
تقنية التمكين الأساسية هي بوابة صامتة التشفير. تقنية التشفير هذه [تسمح بعتبة التشفير] (https://eprint.iacr.org/2024/263) دون الحاجة إلى مرحلة إعداد المفتاح السري التفاعلي الموزع (DKG) المطلوبة للبناء السابق. على العكس من ذلك ، يتم حساب المفتاح المشترك عام بناء على BLSkey عام الحالي وبعض "التلميحات" (التي تمت مناقشتها لاحقا) اليقين.
تم تحقيق اتصال مباشر بين المنشئين والمدققين مع حفظ الخصوصية الرمزية. لا يلزم المدققون تشغيل TEEs أو إدارة أي مواد مفتاحية جديدة.
الآلية:
البناؤون يبنون كتلة ويشفرونها إلى لجنة التحقق.
يبني البنّاء إثباتًا لـ TEE ويثبت لجنة التحقق ثلاث جوانب: أن العرض صادق وأن الكتلة صالحة وأن التشفير صحيح.
البنّاء سيلقي بكتلة وإثبات TEE بالحد الأدنى للتشفير (بما في ذلك القيمة المُعرَضة) على المُقترِح. [3]
المقترح يقوم بتوقيع بناء الفائز مع التشفير ونقل الاقتراح إلى مجموعة المحققين.
عندما يقوم اللجنة المعتمدة بنسبة معينة (مثل n/2 أو 2n/3) بتوثيق الكتلة، فإنها ستُفك تشفيرها.
الكتلة المفككة ستتم تأكيدها النهائي بشكل طبيعي.
ملاحظات
الأداء
أداء الباب الصامت للتشفير له ميزات مفيدة للغاية. هنا، n هو أقصى حجم للجنة التي نأمل دعمها، و t هو حد الفك.
التشفير وجزء فك التشفير يستغرقان وقتًا ثابتًا. باستخدام التنفيذ البسيط، يستغرق الالتشفير أقل من 7 مللي ثانية ويمكن توازيته. وقت جزء فك التشفير أقل من 1 مللي ثانية.
النص المشفر أكبر بحجم من النص العادي بمقدار 768 بايت، وهذا عامل ثابت (بالنسبة لأي n و t).
جزئياً ، يعتمد الفك المجمع (أي فك التشفير) على حجم اللجنة. عندما n=1024 ، يكون الوقت المستغرق في التنفيذ البسيط أقل من 200 مللي ثانية. نتوقع أن يقل هذا الوقت بمقدار 10 أضعاف عندما n=128 (حجم اللجنة للمصادقة في كل فترة) ، ويمكن تحسين التنفيذ بشكل أكبر.
الأهم هو أن وقت التشفير هو مؤشر أداء حيوي يتم مقارنته مع وقت الإستجابة للمناوبة. هذا هو ما يجب على المُنشئين حسابه ضمن "المسار الحرج" الذي تتم فيه إنشاء الكتل. يجب أن يكون هذا الوقت أقل من وقت الإستجابة للمناوبة الحالي ويجنب الاتصالات المتعددة.
إصدار البيانات
بوابة الصمت التشفير ليست مجانية تمامًا. فهي تحتاج حقًا إلى سلسلة مرجعية مشتركة بتنسيق (g، gτ، gτ²، ...، gτⁿ⁻ᵗ) ، مماثلة لما يستخدم في خطة الإلتزام بالمعاملات الكثيرة لـ KZG.
بالإضافة إلى ذلك ، يقوم كل مدقق بمفتاح عام BLS بتحرير مجموعة من العناصر الجماعية التي نطلق عليها "التلميحات" والتي تأخذ الشكل (g⁽ˢᵏ⁾⋅τ ، ..., g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ) ، والتي لا تحتاج إلى الاستخدام إلا عند تجميع المفتاح العام وفك تشفير النص المشفر. يستخدم التشفير مفتاح عام مجمع ثابت الحجم فقط.
حتى كتابة هذا المقال، هناك حوالي 1000000 المدققون. إذا قمنا بتعيين n=128 و t=n/2، فإن كل المدقق يحتاج إلى نشر حوالي 3KB من التلميحات. وبالتالي، تخزين جميع تلميحات المدققين يتطلب 3GB من المساحة.
مع تنشيط MaxEB، قد يتم إسقاط هذا المطلب بشكل كبير، يسمح MaxEB للمدققون بالتحكم في أرصدة أكبر من 32 ETH تحت نفس المفتاح السري (بدلاً من تقسيمها إلى عدة وديعات من 32 ETH). لا يزال هناك مناقشة مستقبل تقليل مجموعات المدققين المُنفذة. قد نقللها إلى حوالي 1 جيجابايت.
وأخيرًا، وفقًا لتغييرات مستقبلية في هيكل إثيريوم (مثل تقليل مزيد من المدققون أو استبدال خط الإنتاج النهائي)، قد يكون من الضروري تقليل حجم الحافظة المطلوب تخزينها بشكل أكبر.
الحيوية
تطلع إثيريوم على البقاء على الإنترنت في ظروف الشبكة غير المواتية. أحد المشاكل في هذا النهج هو أنه قد يحدث كتلة غير قابلة للفكرة بسبب عدم تواجد لجنة محددة بنسبة معينة.
إحدى الحلول هي السماح للبناء بتحديد نسبة اللجان المقبولة (t) للاسترجاع. هناك توازن بين الخصوصية (إمكانية فك التشفير وسرقة MEV) واحتمال وجود عتبة للجنة. بالنسبة للبنائين ، يكون إدراج كتلهم في السلسلة بدلاً من الشوكة هو تحقيق أقصى قدر من الإيرادات ، لذا يجب أن يجدوا إعدادًا للعتبة المحسنة.[4]
بالإضافة إلى ذلك ، يجب أن يكون استخدام نظام التشفير هذا طوعيا. في ظل ظروف الشبكة المعاكسة ، إذا لم تكن هناك لجان ذات حجم مقبول يمكن أن تظل على الإنترنت ، يمكن للمؤيدين والبنائين العودة إلى استخدام المرحلات أو البناء الذاتي أو الآليات الأخرى التي يختارونها اعتمادا على طبيعة البيئة المعاكسة.
بشكل محدد، يكون القيمة المتوقعة لبنّاء الكتلة التي يتم فوركها سلبية (لا يتلقون أي دخل منها)، بينما تكون القيمة المتوقعة للفك المتوقعة سلبية جدًا. إذا كان على بنّاء الكتلة اختيار t في [0، 128]، فسيكون من المنطقي تحفيزهم على اختيار t عالي بما يكفي لإسقاط خطر الفك وزيادة احتمال الوفاء (مع وجود على الأقل t من أعضاء المجلس متصلين). في ظل ظروف الشبكة العادية، قد يتم فورك بعض الكتل، ولكننا نلاحظ أن هذا قد حدث بالفعل في لعبة الوقت، وأن نشاط السلسلة لا يزال مقبولًا. ↩
الكتلة غير متاحة
بالإضافة إلى ذلك ، قد يكون اللجنة عبر الإنترنت ، ولكن قد يتمكن المنشئون من إنشاء حالة تجعل الكتلة غير قابلة للفك أو غير صالحة عند فك تشفيرها (على سبيل المثال ، باستخدام إثبات خادع).
من وجهة نظر البروتوكول، يمكن تحويل هذه الكتل fork. فقط لا يمكن للمدققون العاملين على نطاق واسع إثبات هذا النوع من الكتل أو أي كتلة تشير إليها. ربما أفضل طريقة لمعالجة هذا الخطأ هي جعل عميل الإجماع يدرك هذا الاحتمال وقادرًا على الفشل بشكل أنيق. هذا يتطلب مزيد من البحث.
هيكل السوق
بناء الفائز يعرف محتوى الكتلة قبل الوصول إلى العتبة، وهذا يمكن أن يؤدي إلى ميزة غير عادلة في الفترة اللاحقة. ومع ذلك، يجب أن يتخذ اللجنة الإثباتية إجراءات قبل نهاية الفترة الزمنية التالية، وبما أن القيمة الكبيرة للكتلة تتركز في نهاية الفترة الزمنية، فإن تأثير هذه الميزة يجب أن يكون أدنى قدر ممكن.
إثبات تشفير نقي
من وجهة نظر طويلة الأمد، قد تكون هناك فرصة لاستخدام الإثبات دون معرفة (ZK الإثبات) بدلاً من إثبات TEE. حالياً، سرعة ZK الإثبات بطيئة للغاية، ولكن التقدم في علم الكلمات السرية، والبرمجيات، والأجهزة المخصصة (ASICs) قد يجعل في النهاية إنتاج ZK الإثبات ممكنًا ضمن الحدود الزمنية الضرورية. يجدر بالذكر أن الإثبات بمساعدة الكتلة هو جزء أساسي من خريطة طريق إيثريوم على المدى الطويل.
تبنى
وفقًا لحجم المدققين الحالي ومعدل نمو مجموعة البوابة ، قد لا يكون هذا الخيار جديرًا بالنشر في L1 بسبب كمية البيانات المطلوبة. ومع ذلك ، يخطط ETH لتقليل كمية المدققين بشكل كبير من خلال MaxEB.
قد يكون الأفضل ترقية العميل قبل أو بعد MaxEB، بحيث يمكن لعميل الإجماع أن يدرك إمكانية تشفير الكتلة ويشجع المدققين على إصدار تلميحات. على سبيل المثال، بعد MaxEB، يمكن أن يُطلب من المدققين الجدد إصدار تلميحات، في حين يمكن للمدققين القدامى الحصول على حوافز للترقية.
عندما يتم اعتماد العدد الكافي من المدققون لهذا الآلية، سيبدأ البنّاءون في استخدامها لضمان وجود حجم كاف من اللجان (أي، موازنة بين الخصوصية وإمكانية فك التشفير).
إذا كانت طريقتنا فعلاً أفضل فيما يتعلق بوقت الاستجابة من الإعادة التوجيه متعدد القفزات، فمن المفترض أن يتبناها السوق تلقائيًا بدون الحاجة إلى استخدام البروتوكول أو تحديد إعدادات معينة للمعلمات.
المبادئ الأساسية
المناوبة هي واحدة من أهم مصادر اللامركزية في إيثريوم المركزية، مما يؤدي إلى فرص الإيجار وتشويه بروتوكول اللامركزية الجغرافية. نحن بحاجة إلى إزالة الوسيط ونعتقد أن هذا هو حل نسبي أنيق. يتطلب تغييرًا في طبقة التوافق ، ولكن لا يلزم الكشف عن مفتاح سري جديد أو مواد. المدققون.
العيب هو أنها تعديل معقد لطبقة الاتفاق، وميكانيكية مثل هذه (إذا تم اعتمادها اختياريا كما هو مقترح) قد يتم قبولها من قبل السوق وقد لا يتم. ومع ذلك، تواجه أيضًا العديد من تغييرات قنوات MEV المحتملة نفس المشكلة التي تتعلق بالتبني وتحقيق أقصى استفادة (على سبيل المثال، قائمة الاستدراجات المشتركة ). ومستقبلاً قد يعتمد بعض الحالات الأخرى على المدققون الذين يمتلكون بنية تحتية مشفرة.
إخلاء المسؤولية: